EP11. LLM 평가 기준과 방법

LLM을 단일 모델 절대 평가와 교차 평가 두 축으로 측정하고, 5가지 평가 기준(지식·이해, 추론력, 대화 품질, 인간 선호, 안정성) 및 PPL(Perplexity) 지표를 활용해 도메인에 맞는 모델을 선택·검증합니다.

0. 사전 필수 용어 (선행지식)

본 주제를 이해하기 전에 다음 5개 용어를 먼저 파악합니다.

1. 할루시네이션 (Hallucination): LLM이 사실과 다른, 그럴듯하지만 틀린 정보를 생성하는 현상입니다. "AI가 없는 논문을 인용한다"처럼 모델이 자신 있게 오답을 만들어 내는 상황을 말합니다. 본문 §3(점수 시스템 설계), §9(한계)에서 반복 등장합니다.

2. PPL (Perplexity): 모델이 주어진 텍스트를 얼마나 잘 예측하는지 수치화한 지표입니다. "낮을수록 해당 텍스트를 잘 예측한다"는 의미이며, 반드시 코퍼스 기반 데이터셋에만 적용됩니다. 본문 §3(PPL), §4 Step 5, §6에서 계산 방법과 제약이 설명됩니다.

3. 벤치마크 (Benchmark): 모델 성능을 측정하기 위해 표준화된 테스트 세트와 평가 절차의 묶음입니다. MMLU, ARC, BBH, Arena-Hard 등이 대표적입니다. 본문 §3, §4, §5에서 기준별 대표 벤치마크가 나열됩니다.

4. 컴플리션 (Completion) vs 코퍼스 (Corpus):

5. 컴플리션: 학습 데이터 형태로, 질문-답변처럼 쌍(pair)으로 구성됩니다. A를 주면 B가 나오도록 유도합니다.
6. 코퍼스: 평가 데이터 형태로, 단일 팩트 기반 단일 문장으로 구성됩니다. PPL 계산에 사용됩니다.

7. 본문 §3(컴플리션 vs 코퍼스), §4 Step 5에서 구분의 실무적 의미가 설명됩니다.

8. 교차 평가 (Pairwise Evaluation / Preference Evaluation): 두 개 이상의 모델 출력을 나란히 놓고 "어느 쪽이 더 좋은가"를 묻는 비교 방식입니다. Elo 레이팅처럼 상대 점수로 모델 순위를 매깁니다. 본문 §3(교차 평가), §4 Step 4에서 구현 방법이 다루어집니다.

📚 참고: 선행 지식이 부족하면 AI 엔지니어링 EP9 (LLM 모델 평가의 개요와 기준) 또는 EleutherAI lm-evaluation-harness 공식 문서를 먼저 확인합니다.

1. 주제 정의

LLM 평가 기준과 방법은 거대 언어 모델(LLM)의 성능을 측정·비교하기 위해 절대 평가(단일 모델)와 교차 평가(복수 모델 비교)를 조합하고, 지식·추론력·대화 품질·인간 선호·안정성 다섯 기준과 PPL 지표를 체계적으로 적용하는 방법론입니다.

핵심 아이디어: 평가 방법마다 비용·속도·할루시네이션 위험이 다르므로, 목적과 예산에 맞는 방법을 선택하고 조합해야 합니다.

2. 풀려는 문제

다음 네 가지 실무 시나리오에서 LLM 평가가 필요합니다.

• 문제 1 — 모델 선택 의사결정: 서비스에 투입할 LLM을 고를 때 객관적 지표 없이 "비싼 모델 = 좋은 모델"로 결정하면 에이전트 구현이 복잡해지고 비용이 과다 발생합니다.
• 문제 2 — 파인튜닝 효과 측정: 기반 모델을 파인튜닝할 때마다 성능이 개선되었는지 재평가가 필요합니다. 평가 없이 튜닝만 반복하면 퇴화 여부를 알 수 없습니다.
• 문제 3 — 도메인 특화 모델 검증: 의료·법률·코드 도메인에서 일반 벤치마크(MMLU 등)가 아닌 도메인 팩트 기반 PPL 또는 전용 벤치마크(MedQA, HumanEval 등)가 필요합니다.
• 문제 4 — 안전성·사실성 검증: 모델이 위험한 지식을 생성하거나 사실과 다른 정보를 자신 있게 출력하는 문제를 사전에 감지해야 합니다.

💡 실무 노하우: 파운데이션 모델 3개 × 튜닝 버전 n개를 평가하면 평가 항목이 기하급수적으로 늘어납니다. 먼저 빠른 절대 평가로 후보를 추려낸 뒤 교차 평가로 최종 선택하는 2단계 전략이 비용 효율적입니다.

3. 핵심 개념·구조

LLM 평가 방법론은 다음 두 축과 다섯 기준으로 구성됩니다.

3-1. 평가 방법 두 가지

• 단일 모델 평가 (절대 평가): 모델 하나를 독립적으로 평가합니다.
• 점수 시스템: 1~5점처럼 분류에 가깝게 설계 → 할루시네이션 감소. LLM 1회 호출 → 비용·속도 유리.
• 참/거짓 판정: 다수 항목을 반복 검사 → 비용·속도 불리. 점수화(scoring) 로직 별도 필요.

• 유사도 평가: 정해(Ground Truth)와 출력 사이 임베딩 유사도 측정. 비용·속도 유리. NLP 의미 만족도 보장 어려움.

• 교차 평가 (선호도 평가): 두 모델 출력을 나란히 놓고 "A vs B 중 어느 쪽이 더 좋은가"를 묻습니다.

• 절대 평가가 완료된 기준 모델(예: 70점)과 비교하여 신규 모델 점수를 간접 예측합니다.
• Elo Rating: 체스 레이팅처럼 승/패 기록을 누적해 모델 순위를 산출합니다.

3-2. 5가지 평가 기준 및 대표 벤치마크

3-3. PPL과 데이터 형태

학습 데이터 (Completion)     평가 데이터 (Corpus)
────────────────────         ──────────────────────
질문 → 답변 (pair)           단일 팩트 문장
A를 주면 B가 나오도록         모델이 해당 문장을
훈련 유도                    얼마나 잘 예측하는지
                             → PPL 계산 가능

⚠️ 주의: PPL은 반드시 코퍼스 기반 데이터셋에만 적용합니다. 컴플리션 데이터로 PPL을 계산하면 측정값이 무의미합니다.

3-4. 도메인 특화 모델 평가 흐름

도메인 팩트 나열
     ↓
코퍼스 데이터셋 구성
     ↓
PPL 측정 (오픈소스 모델만 가능)   또는   도메인 전용 벤치마크 실행
     ↓                                      ↓
낮은 PPL = 해당 도메인 이해도 높음        코드: HumanEval·MBPP
                                           의료: MedQA·PubMedQA
                                           검색/RAG: Recall·Precision

4. 구현 가이드 (Do It Yourself)

시작 전 (Before you begin)

이 섹션을 완료하면 LLM 평가 파이프라인을 실제 코드로 구현하고 검증할 수 있습니다.

선수 조건: - Python 3.10+ - 필요 라이브러리 설치: bash pip install openai anthropic transformers torch datasets lm-eval - API 키 환경 변수 설정: bash export OPENAI_API_KEY="sk-..." export ANTHROPIC_API_KEY="sk-ant-..."

소요 시간: 약 25~30분.

Step 1 — 절대 평가: 점수 시스템 (LLM-as-Judge)

목표: Claude를 LLM-as-judge로 사용해 1~5점 절대 채점을 구현합니다.

다음 코드를 evaluate_absolute.py에 추가합니다.

import anthropic

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY 환경변수 자동 참조

def score_response(question: str, answer: str) -> dict:
    """
    LLM-as-judge 절대 평가 (1~5점 분류).

    Args:
        question: 평가 대상 질문
        answer: 평가 대상 모델 출력
    Returns:
        {"score": int, "reason": str}
    """
    prompt = f"""다음 답변을 1~5점으로 평가하세요.
1=완전 오답, 2=대부분 틀림, 3=보통, 4=대부분 맞음, 5=완벽한 답변

반드시 JSON으로만 응답: {{"score": <1~5 정수>, "reason": "<근거 1문장>"}}

질문: {question}
답변: {answer}"""

    message = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}]
    )
    import json
    return json.loads(message.content[0].text)

이 코드는 Claude를 채점관으로 사용해 1~5점 분류 평가를 수행합니다.

⚠️ 주의: 점수 범위를 1~10처럼 크게 설정하면 할루시네이션이 증가합니다. 1~5 분류에 가깝게 설계하세요. 점수 경계마다 기준을 명시하면 할루시네이션이 추가로 줄어듭니다.

💡 실무 노하우: LLM-as-judge의 자기 선호(vendor self-preference) 편향을 피하기 위해 다른 벤더 모델을 채점관으로 사용합니다. 예: 평가 대상이 Claude이면 채점관은 GPT-4o를 사용합니다.

📚 참고: OpenAI Cookbook — LLM evaluation patterns

✅ 확인: Step 1 완료. score_response("2+2는?", "4입니다") 호출 후 {"score": 5, "reason": "..."} 형식의 JSON이 반환되면 정상입니다.

Step 2 — 절대 평가: 참/거짓 판정 (Boolean 평가)

목표: 다수 항목에 대해 True/False 판정을 수행하고 최종 점수로 집계합니다.

def boolean_eval(questions_answers: list[dict]) -> dict:
    """
    참/거짓 판정 후 점수화(scoring).

    Args:
        questions_answers: [{"question": str, "expected": str, "actual": str}, ...]
    Returns:
        {"total": int, "correct": int, "score": float}
    """
    correct = 0
    for item in questions_answers:
        prompt = (
            f"질문: {item['question']}\n"
            f"정답: {item['expected']}\n"
            f"모델 출력: {item['actual']}\n"
            "모델 출력이 정답과 동일한 의미면 true, 아니면 false. "
            "JSON만 출력: {\"correct\": true/false}"
        )
        message = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=64,
            messages=[{"role": "user", "content": prompt}]
        )
        import json
        result = json.loads(message.content[0].text)
        if result.get("correct"):
            correct += 1
    total = len(questions_answers)
    return {"total": total, "correct": correct, "score": correct / total * 100}

⚠️ 주의: 참/거짓 판정은 항목 수만큼 LLM을 호출합니다. 100개 질문이면 API 호출 100회 → 비용·시간이 점수 시스템 대비 수십 배 발생합니다.

✅ 확인: Step 2 완료. 소규모 테스트 셋(5문항)으로 boolean_eval 실행 후 {"total": 5, "correct": N, "score": ...} 반환을 확인합니다.

Step 3 — 절대 평가: 유사도 평가

목표: 정해(Ground Truth)와 모델 출력 사이의 임베딩 코사인 유사도를 측정합니다.

from openai import OpenAI
import numpy as np

oa_client = OpenAI()  # OPENAI_API_KEY 환경변수 사용

def cosine_similarity(v1: list, v2: list) -> float:
    a, b = np.array(v1), np.array(v2)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

def similarity_eval(expected: str, actual: str) -> float:
    """코사인 유사도로 0~1 점수 반환."""
    emb = oa_client.embeddings.create(
        model="text-embedding-3-small",
        input=[expected, actual]
    )
    return cosine_similarity(emb.data[0].embedding, emb.data[1].embedding)

⚠️ 주의: 유사도가 높아도 NLP 의미가 다를 수 있습니다. RAG 구현에서 "유사도는 높은데 왜 이 문서가 관련 있지?"라는 상황이 자주 발생합니다. 유사도 평가는 빠른 1차 필터로 사용하고, 최종 판정은 LLM-as-judge로 보완합니다.

✅ 확인: Step 3 완료. 동일 문장 쌍은 유사도 ≈ 1.0, 전혀 다른 주제 문장 쌍은 유사도 ≈ 0.1 이하로 확인합니다.

Step 4 — 교차 평가: Pairwise A/B + Elo Rating

목표: 두 모델 출력을 비교하고 Elo 레이팅으로 상대 순위를 산출합니다.

def pairwise_preference(question: str, answer_a: str, answer_b: str) -> str:
    """
    A vs B 선호도 평가.
    Returns: "A" | "B" | "tie"
    """
    prompt = (
        f"질문: {question}\n\n"
        f"답변 A: {answer_a}\n\n"
        f"답변 B: {answer_b}\n\n"
        "어느 답변이 더 정확하고 유용한가요? JSON만 출력: "
        "{\"winner\": \"A\" or \"B\" or \"tie\", \"reason\": \"<근거>\"}"
    )
    message = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}]
    )
    import json
    return json.loads(message.content[0].text)["winner"]


def update_elo(rating_a: float, rating_b: float, winner: str,
               k: float = 32) -> tuple[float, float]:
    """Elo 레이팅 업데이트."""
    ea = 1 / (1 + 10 ** ((rating_b - rating_a) / 400))
    eb = 1 - ea
    if winner == "A":
        sa, sb = 1.0, 0.0
    elif winner == "B":
        sa, sb = 0.0, 1.0
    else:
        sa, sb = 0.5, 0.5
    return rating_a + k * (sa - ea), rating_b + k * (sb - eb)

💡 실무 노하우: 절대 평가가 완료된 기준 모델(예: 70점)이 있으면, 신규 모델이 기준 모델보다 선호도에서 이기는 비율로 간접 점수를 추정할 수 있습니다. 모든 후보를 절대 평가할 필요가 없어 비용이 절감됩니다.

✅ 확인: Step 4 완료. 두 모델에 동일 질문 10개 입력 후 Elo 점수 차이가 직관적 품질 차이와 일치하는지 확인합니다.

Step 5 — PPL 계산 (코퍼스 기반)

목표: HuggingFace transformers로 오픈소스 모델의 PPL을 측정합니다.

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

def compute_ppl(model_name: str, corpus_sentences: list[str]) -> float:
    """
    코퍼스 기반 PPL 계산.

    Args:
        model_name: HuggingFace 모델 ID (예: "meta-llama/Llama-3.2-1B")
        corpus_sentences: 단일 팩트 문장 리스트 (코퍼스)
    Returns:
        PPL 값 (낮을수록 해당 코퍼스를 잘 예측)
    """
    tokenizer = AutoTokenizer.from_pretrained(model_name)
    model = AutoModelForCausalLM.from_pretrained(
        model_name, torch_dtype=torch.float16, device_map="auto"
    )
    model.eval()

    total_loss, total_tokens = 0.0, 0
    with torch.no_grad():
        for sentence in corpus_sentences:
            inputs = tokenizer(sentence, return_tensors="pt").to(model.device)
            loss = model(**inputs, labels=inputs["input_ids"]).loss
            total_loss += loss.item() * inputs["input_ids"].size(1)
            total_tokens += inputs["input_ids"].size(1)

    import math
    return math.exp(total_loss / total_tokens)

⚠️ 주의: PPL은 컴플리션 데이터(질문-답변 쌍)로 계산 불가합니다. 반드시 코퍼스 기반 단일 팩트 문장 리스트를 사용합니다. AI 업계에서 "코퍼스 기반 PPL을 돌렸다"고 명시하는 이유는 컴플리션과 구분하기 위해서입니다.

⚠️ 주의: PPL은 오픈소스 모델에만 직접 측정 가능합니다. GPT-4o·Claude 같은 상용 API 모델은 모델 가중치에 접근할 수 없으므로 PPL 직접 측정이 불가합니다.

💡 실무 노하우: 도메인 특화 모델 선택 시, 해당 도메인 팩트 코퍼스로 PPL을 측정하면 일반 벤치마크보다 직접적인 지표가 됩니다. 예: 의료 도메인이면 의학 교과서 문장 100개로 PPL을 비교합니다.

✅ 확인: Step 5 완료. 동일 코퍼스에 대해 도메인에 특화된 모델이 일반 모델보다 낮은 PPL을 기록하는지 확인합니다.

Step 6 — 통합 평가 파이프라인 (lm-evaluation-harness)

목표: EleutherAI lm-evaluation-harness로 MMLU·ARC·HellaSwag 등 표준 벤치마크를 실행합니다.

# 설치
pip install lm-eval

# 평가 실행 (로컬 HuggingFace 모델)
lm_eval \
  --model hf \
  --model_args pretrained=meta-llama/Llama-3.2-1B \
  --tasks mmlu,arc_challenge,hellaswag,gsm8k \
  --batch_size 8 \
  --output_path ./eval_results/

💡 실무 노하우: lm-evaluation-harness는 Open LLM Leaderboard의 백엔드입니다. 새 모델을 도입할 때 가장 먼저 사용하는 표준 도구입니다. --tasks 옵션에 도메인 전용 태스크(humaneval, medmcqa 등)를 추가해 도메인 평가를 통합할 수 있습니다.

📚 참고: EleutherAI lm-evaluation-harness — 200개 이상 태스크 지원.

✅ 확인: Step 6 완료. eval_results/ 디렉토리에 JSON 결과 파일이 생성되고, mmlu 정확도가 출력되면 정상입니다.

Step 마지막 — 동작 확인 (통합 테스트)

# evaluate_test.py
from evaluate_absolute import score_response

result = score_response(
    question="파이썬에서 리스트를 정렬하는 방법은?",
    answer="sorted() 함수 또는 list.sort() 메서드를 사용합니다."
)
print(result)

예상 출력:

{"score": 5, "reason": "정확하고 간결하게 두 가지 방법을 모두 설명했습니다."}

5. 적용 사례 (공신력 오픈소스 5가지+)

LLM 평가 도메인의 대표 오픈소스 도구입니다.

• EleutherAI lm-evaluation-harness (https://github.com/EleutherAI/lm-evaluation-harness) — Open LLM Leaderboard 백엔드. MMLU, ARC, HellaSwag, HumanEval 등 200개 이상 태스크 표준화 평가. GitHub 스타 7K+.
• OpenAI Evals (https://github.com/openai/evals) — LLM eval 프레임워크. 커스텀 eval registry 지원. JSON/YAML 기반 평가 정의. GitHub 스타 14K+.
• DeepEval (https://github.com/confident-ai/deepeval) — G-Eval(LLM-as-judge 표준화), hallucination metric, RAG 평가 지표 포함. GitHub 스타 5K+.
• HELM (Stanford CRFM, https://github.com/stanford-crfm/helm) — Holistic Evaluation of Language Models. accuracy·robustness·fairness·bias·efficiency 다각도 평가. Stanford 공식 프로젝트.
• Promptfoo (https://github.com/promptfoo/promptfoo) — 프롬프트 회귀 테스트, 사이드바이사이드 비교, CI/CD 통합. GitHub 스타 5K+.
• RAGAS (https://github.com/explodinggradients/ragas) — RAG 전용 평가 (faithfulness, answer relevancy, context precision/recall). RAG 파이프라인 품질 측정 표준. GitHub 스타 7K+.
• LangChain (https://github.com/langchain-ai/langchain) — LangSmith eval, criteria evaluator, pairwise comparison 내장. LLM 애플리케이션 평가 워크플로와 통합 용이.
• LMSYS Chatbot Arena (https://github.com/lm-sys/FastChat) — 인간 pairwise 선호도 + Elo 레이팅. Chatbot Arena 공개 리더보드의 실제 구현체.

📚 참고: 위 도구들은 모두 GitHub 스타 5K 이상이거나 Anthropic·OpenAI·Stanford·EleutherAI 공식 프로젝트입니다.

💡 실무 노하우: lm-evaluation-harness가 사실상 LLM 벤치마킹 표준입니다. 새 오픈소스 모델 도입 시 첫 번째로 실행합니다. RAG 시스템 평가에는 RAGAS를, 프롬프트 회귀 테스트에는 Promptfoo를 조합합니다.

6. 핵심 원리

원리 1 — 할루시네이션 최소화를 위한 분류 설계

점수 시스템을 1~10처럼 넓게 설계하면 LLM이 "7점은 언제고 8점은 언제인가"를 결정하는 과정에서 할루시네이션이 증가합니다. 1~5처럼 분류(classification)에 가깝게 설계하고, 각 점수의 기준을 프롬프트에 명시하면 판정 일관성이 높아집니다.

원리 2 — PPL의 데이터셋 의존성

PPL은 "모델이 이 코퍼스를 얼마나 잘 예측하는가"를 측정합니다. 코퍼스가 도메인 팩트로 구성될수록 도메인 이해도를 직접 반영합니다. 반대로 컴플리션(질문-답변 쌍)으로 PPL을 계산하면 학습 방식 자체의 영향이 섞여 의미 있는 지표가 되지 않습니다.

원리 3 — 평가 투자 = 구현 범위 축소

정교한 모델을 올바르게 선택하면 에이전트 구현 범위가 줄어듭니다. 비용이 저렴한 모델을 빠르게 채택하면 모델 한계를 프롬프트 엔지니어링과 에이전트 로직으로 보완해야 하므로 장기 유지비용이 증가합니다.

7. 변형·확장

• G-Eval (DeepEval 구현): LLM-as-judge를 단계별 체인오브소트(Chain-of-Thought)로 표준화. 단일 점수 외에 세부 기준별 점수 산출.
• LLM-as-jury: 여러 채점관 LLM의 합의(majority vote)로 편향 감소. 3개 채점관 중 2개 이상 동의 시 채택.
• MT-Bench / MT-Bench-101: 멀티턴 대화 품질 평가. 단발성 Q&A가 아닌 대화 연속성을 측정.
• Inspect AI (UK AISI): 안전성 특화 eval 프레임워크. Constitutional AI 관점의 평가.
• Constitutional AI Evaluation (Anthropic): 모델이 헌법적 원칙을 위반하는지 체계적으로 평가.
• RLHF 기반 평가: 인간 피드백 강화학습 파인튜닝 후 선호도 점수 변화 추적.

8. 다른 도구·접근과의 비교

💡 실무 노하우: 오픈소스 모델 벤치마킹은 lm-evaluation-harness, 커스텀 프롬프트 회귀 테스트는 Promptfoo, RAG 파이프라인 품질은 RAGAS를 각각 사용하는 조합이 효율적입니다.

9. 한계·트레이드오프

1. 벤치마크 오염 (Benchmark Contamination): 벤치마크 데이터가 학습 데이터에 포함되어 점수가 실제 능력을 과대평가하는 문제. MMLU는 수명이 다해 MMLU Pro 전환이 권장됩니다.

2. LLM-as-judge 편향:

3. 자기 선호(vendor self-preference): 채점관과 동일 벤더 모델이 더 높은 점수를 받는 경향.
4. 위치 편향(position bias): A/B 비교에서 먼저 제시된 답변을 선호하는 경향.

5. 장황함 편향(verbosity bias): 긴 답변을 무조건 선호하는 경향.

6. 인간 평가 비용·일관성 부족: Chatbot Arena 같은 인간 선호 평가는 평가자 간 불일치(inter-annotator disagreement)가 크고, 대규모 평가는 비용이 매우 높습니다.

7. 도메인 일반화 부족: 일반 벤치마크(MMLU 등)의 고점이 실제 도메인 성능을 보장하지 않습니다. 도메인 특화 평가 없이 모델을 선택하면 운영에서 실망스러운 성능이 나올 수 있습니다.

8. 상용 모델 PPL 측정 불가: GPT-4o·Claude 같은 API 전용 모델은 가중치에 접근할 수 없으므로 PPL 직접 측정이 불가합니다. 오픈소스 대안 모델과 비교하는 간접 방법으로 대체해야 합니다.

10. 최신 권장 패턴 (2026 기준)

• Constitutional AI Evaluation (Anthropic): 모델이 해악·불정직·위험 지식 생성을 얼마나 잘 거부하는지 구조적으로 평가.
• Inspect AI (UK AISI, https://github.com/UKGovernmentAEIS/inspect_ai): 영국 AI 안전연구소(AISI)의 안전성 평가 프레임워크. 표준화된 safety eval.
• MT-Bench-101: 멀티턴 대화 101가지 시나리오 평가. 단발 Q&A 한계를 극복.
• LLM-as-jury: 3개 이상 이종 채점관 합의 → 단일 채점관 대비 편향 대폭 감소.
• RAG-specific evals (RAGAS, TruLens): retrieval 품질(context precision/recall)과 생성 품질(faithfulness, answer relevancy)을 분리 측정.
• Reasoning 전용 벤치마크 강화: MATH, DROP, HotpotQA 외 AIME, LiveCodeBench 등 동적 갱신 벤치마크 채택으로 contamination 문제를 완화.

11. 메타인지 자기평가

본인 코드·시스템에 LLM 평가 파이프라인을 적용하기 위한 검증 절차입니다.

Step 1 — 현재 상태 점검

# 현재 프로젝트에 평가 로직이 있는지 확인
grep -r "evaluate\|score\|benchmark\|ppl" your_project/ --include="*.py"

Step 2 — 적용 가능성 평가

• 조건 1: 평가 데이터셋(질문-답변 쌍 또는 코퍼스 문장)이 준비되어 있는가?
• 조건 2: 평가할 모델이 오픈소스(HuggingFace)인가, API 전용인가? (PPL 가능 여부 결정)
• 조건 3: LLM-as-judge 사용 시 judge 모델이 평가 대상 모델과 다른 벤더인가?
• 조건 4: 도메인 특화 평가가 필요한가? (도메인 코퍼스 데이터셋 구성 필요)

Step 3 — 점진 적용 로드맵

1. 1단계: 절대 평가(점수 시스템 1~5점) 구축 → 가장 빠르게 도입 가능.
2. 2단계: 교차 평가(A/B Pairwise + Elo) 추가 → 모델 비교 시 비용 절감.
3. 3단계: 도메인 특화 벤치마크 또는 PPL 측정 → 도메인 모델 선택의 근거 확보.
4. 4단계: CI/CD 통합 (Promptfoo 또는 lm-eval) → 모델 업데이트마다 자동 회귀 테스트.